In computer related technologies, current disaster management techniques in distributed systems are naïve. Some distributed architectures have a master slave configuration, where some databases are treated as slaves and some as masters. The slave databases serve read requests from clients, but not write requests (at least not directly). The write requests are routed to master databases which may be in different locations/regions. The data may then be replicated from the master databases to the slave databases, for example, in batches.
Current architectures are slow, inefficient, and have high write latency. For example, in a master slave environment, the master and slave databases can be disparate regions, “Region A” and “Region B,” respectively. The turn around time for processing a write request from “Region B” by sending to the master in “Region A” may be, for example, hundreds of milliseconds. If the user performs more things in a write request, the latency may be seconds. Further, in cases where the master and slave databases are farther apart, the latency may be more. So users would start seeing slower responses for write requests.
Current architecture is less reliable at least due to a higher percentage of failure of master databases. If the master fails, write requests from the slave region will not be supported and thus, that part of the distributed system in regions with the slave databases is unavailable. Further, such architecture results in lower availability when network to regions having master databases fails. The current architecture may be suitable for environments that have low-write loads, where the write heavy products or services are either served only from one region, and where potential simultaneous updates from multiple regions are ignored.